Level Geometry (Level Design)
Halo content or game assets (levels, vehicles, weapons, characters, etc...) are created using arbitrary polygons. Arbitrary polygons and arbitrary polygon modeling has several advantages including the ability to create complex shapes and surfaces that can be either concave or convex and flexible texture mapping including UVW mapping. The arbitrary polygons are created or modeled using a 3D modeling program such as 3D Studio Max (3ds Max) or equivalent. Halo was created using 3ds Max 3.x on the Xbox and the additional content for the PC version was created using 3ds Max 5.1. Polygon Count There is a suggested amount of 10,000 polygons that should be used to construct a multiplayer level. This value corresponds to the construction limit for the world mesh or model for the level, the basic core geometry for the level. Additional scenery objects that are placed as models are handled in the following section for Triangle Counts (per scene). These suggested maximum values are guidelines to insure proper exporting and compilation by the tools as well as reasonable polygon amounts for various other technical aspects of the game. Triangle Counts (per scene) There is a suggested amount of 50,000 triangles that should be used to draw a multiplayer level. The values listed are a general guideline due to the fact that performance is affected by many factors other than triangle counts such as the number and type of materials (shaders) in the scene, sounds, dynamic lights, lens flares, and other game objects. As can be expected, the fewer triangles being drawn the better. When creating a level, the level designer should always take into the account additional triangle counts added by vehicles, players, weapons, items, and effects and prepare for any worst case scenarios in terms of triangle counts and rendering. When creating a level, its always a good idea to view a similar level that exists in the original game and see what kind of triangle counts exist per scene at various areas of the level. Checking the triangle counts and other rendering information as well as the frame rate and performance in those areas should give a good baseline during the development of your own multiplayer environment. The level designer should also realize that the triangle counts for a scene compared to the polygon counts for a scene when constructed or viewed in 3DSMax may vary greatly depending on the material used and how that material is rendered in the game. Often, the surface has to be rendered multiple times for the applied material and associated rendering effects and properties set for that material or shader. A simple example, a ladder is constructed with 2 polygons in 3DSMax and a ladder shader is applied to it with the 2-sided property flag checked in the shader due to the fact that the ladder can be viewed from all angles. In game, this 2 polygon ladder will show a triangle count of 4 since BOTH sides are rendered, the back side or back face is not being culled and must be drawn. Technical Rules There are some basic technical rules that must be followed during the creation and construction of a game level in Halo. These rules must be followed to insure that the level will successfully export and compile in order to run in the game. Reference Frame The level MUST have a reference frame with valid geometry linked to the reference frame. If the level does not have a reference frame the Blitzkrieg exporter will not export the .jms file and will give an error dialog "There was no geometry to export". There must also be valid geometry (See Sealed World Rules below) attached or linked to the reference frame or the Blitzkrieg exporter will not export the .jms file and will give an error dialog "There was no geometry to export". For more information on the reference frame for the world mesh please see Creation of a Reference Frame in Level Exporting (Tutorial) page. Sealed World Rules The level MUST be sealed. While other models (those that are placed in the level using .scenery, .vehicle, etc... tags) used in Halo for scenery, characters, weapons and vehicles do not have to be sealed and can have open edges, this does not hold true for the world geometry. The polygons used to construct the world must form a contiguous mesh that forms a sealed volume in order for the level BSP (Binary State Partition) that is used for player collision and physics to be created. The sealed volume and no open edges rule applies to objects that are included in the world mesh (for instance a floating box). As implied in the first paragraph, the sealed world and no open edges rules do not apply to models that are external to the level and are placed or populated in Sapien using their associated tags (.scenery, .vehicle, .weapon, etc...). For more information on creating the world mesh, creating a sealed world, and open edges please see Level Construction (Tutorial) and Terrain Modification (Tutorial) pages. Multiplayer Level Limitations Multiplayer levels are very straight forward and simple in terms of what can be placed in the level and what can operate in the level. The multiplayer game and levels do not have the ability to run the complicated scripting systems that are available in the single player game and levels. These systems are simply not included in the current network architecture that Halo uses for multiplayer. This limits the dynamic objects that can be placed in a multiplayer level since the majority of these kinds of objects (such as doors, light bridges, buttons, etc...) rely on the Halo scripting system to operate. The same holds true for trigger volumes, therefore trigger volumes cannot be used in multiplayer levels. Certain objects that are simple client side effects can be placed in multiplayer levels. Such objects or effects include particle emitters (such as the water fall mist in Timberland), sounds, and other simple objects. Even the Covenant portable force shields used in multiplayer maps like Danger Canyon and Gephyrophobia are not networked. No information gets sent that tells the game server that "the shield has been disrupted". In the case of the Covenant energy shield, the reason it does get turned off on both the client and the server is because the objects that affect the shield (weapons fire and explosions) DO have their information sent over the network and when they get updated on the client it affects the objects in the surrounding area. As a result, these objects can get out of synchronization with the server. This is why the use or heavy use of such objects should be avoided. For more informations see Networking page. Category:Level Design Category:Blam! Category:Engineering